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'  FOREWORD 

v  This  is  Volume  I  of  the  User's  Manual  Component  of  the  Interpreted 
Nuclear  and  Conventional  Theater  Warfare  Simulation  (INWARS)  documentation. 


It  introduces  the  User's  Manual  Component  by  reviewing  the  utilization  of 


INWARS  and  surveying  the  inputs  and  outputs  of  the  simulation. 
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CHAPTER  I 

INTRODUCTION  TO  THE  USER'S  MANUAL 


A.  INTRODUCTION 


This  volume  Introduces  the  User's  Manual  component  of  the  overall 
INWARS  documentation.  In  this  component,  the  emphasis  will  be  on  the  use 
of  the  simulation  which  has  been  described  in  the  Modeling  Description  and 
Software  Description  components  of  the  documentation.  Thus,  concern 
centers  here  on  the  formats  in  which  inputs  are  provided  to  the  simulation, 
and  the  types  of  outputs  produced  by  the  simulation  as  it  runs. 

B.  UTILIZATION  OF  INWARS 


To  provide  some  orientation  towards  the  use  of  INWARS,  this  section 
reviews  the  two  potential  inodes  of  application  discussed  in  the  Synopsis 
component  of  the  documentation.  As  was  emphasized  there,  INWARS  should  not 
be  regarded  as  predictive  of  what  would  "really  happen"  in  a  theater  level 
conflict  situation.  Rather,  it  should  be  regarded  as  a  tool  which  analysts 
can  use  in  investigations  of  various  problems  and  issues,  perhaps  in  con¬ 
junction  with  other  tools,  but  always  in  conjunction  with  their  own  judge¬ 
ment.  To  the  extent  that  INWARS  meets  its  development  objectives,  it  is 
not  a  general  purpose  model,  but  is  rather  better  suited  to  some  types  of 
problems  and  issues  than  others.  Given  the  emphasis  of  scope  over  resolu¬ 
tion,  INWARS  itself  is  not,  for  example,  well -suited  for  evaluation  of 
alternative  major  systems  (e.g. ,  Tank  A  versus  Tank  B).  Based  on  the 
development  objectives,  two  principal  analytical  roles  for  INWARS  applica¬ 
tion  may  be  identified:  INWARS  as  a  doctrine-policy  simulator,  and  INWARS 
as  a  scenario  generator.  The  first  of  these  utilizes  INWARS  by  itself, 
while  the  second  uses  INWARS  in  conjunction  with  other,  more  detailed, 
simulations. 
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1.  INWARS  as  a  Doctrine-Policy  Simulation 

Consistent  with  its  development  objectives,  INWARS  has  been 

designed  to  allow  the  user  to  specify  —  via  input  data  -  a  large  portion 

of  the  doctrines,  policies,  constraints,  and  standard  operating  procedures 

by  which  the  simulated  force  elements  are  to  operate.  These  include,  in 

particular,  concepts  of  operation  to  guide  the  planning  and  execution  of 

ground  operations,  weapons-empl oyment  concepts  and  constraints  to  guide  the 

utilization  of  conventional,  nuclear,  and  chemical  weapons,  and 

threat  response  policies,  to  guide  the  adaption  of  ongoing  operations  to 

2 

changes  in  perceived  nuclear  and  chemical  threat.  INWARS  Cl  elements  at 
echelons  above  division  apply  these  doctrines  and  policies  during  the 
simulation  by  selectively  "fitting'*  them  to  the  (perceived)  situations  they 
face  as  they  plan  operations,  consider  weapons  employment,  and  respond  to 
nuclear  and  chemical  threats.  Thus,  the  actions  of  INWARS  force  elements 
reflect  the  user- input  doctrines  and  policies  as  applied  in  the  specific 
situations  which  arise  In  the  course  of  the  simulated  conflict.  Conse¬ 
quently,  the  course  of  the  simulated  conflict  represents  the  interactions 
among  the  doctrines  and  policies  of  the  opposing  forces. 

To  utilize  INWARS  in  this  doctrine-policy  simulation  role,  an 
initial  configuration  of  force  elements  with  specific  distribution  of 
assets  (major  systems,  etc.)  would  be  postulated.  Likewise,  broad  goals 
for  the  opposing  theaters  would  be  postulated.  Finally,  a  range  of  alterna¬ 
tive  systems  of  doctrines  and  policies  would  be  postulated,  for  one  or  both 
sides.  A  set  of  simulation  runs  would  then  be  conducted,  one  for  each  of 
the  alternative  doctrine- policy  systems  under  consideration.  By  comparing 
the  evolution  and  outcomes  of  the  resulting  simulated  conflicts,  insights 
could  be  gained  into  Impacts  of  the  differeing  doctrines  and  policies.  Of 

course,  even  here,  the  analysis  must  be  tempered  by  the  fact  that  the 
2 

simulated  Cl  elements  are  quite  "doctrinaire":  they  cannot  creatively 
develop  "new"  doctrines  and  policies  as  a  real  commander  might. 
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2.  IHWARS  as  a  Scenario  Generator 

As  INWARS  is  run  and  the  theater- level  conflict  situation 
evolves,  various  situations  may  arise  which  are  of  interest  for  more 
detailed  analysis.  The  entity-based  architecture  of  INWARS  enables  these 
situations  to  be  taken  from  INWARS,  mapped  out,  and  used  as  a  basis  for 
inputs  to  corresponding  more  detailed  models.  In  this  sense,  INWARS  can  be 
used  as  a  "scenario-generator"  for  more  detailed  models.  Thus,  for 
example,  while  INWARS  itself  is  not  well  suited  for  detailed  comparative 
evaluation  of  alternative  major  systems,  it  may  be  used  to  generate  speci¬ 
fic  combat  situations  in  which  to  evaluate  the  alternative  systems  with 
more  detailed  models.  Moreover,  since  the  situations  generated  are  depen¬ 
dent  on  the  user-specified  doctrines  and  policies,  the  role  of  the  alterna¬ 
tive  systems  under  different  broad  forms  of  operation  may,  to  an  extent,  be 
explored. 

C.  PREVIEW  OF  THE  USER'S  MANUAL 

Over  the  remainder  of  this  introductory  volume,  INWARS  inputs  and 

outputs  will  be  surveyed.  Detailed  descriptions  of  inputs  and  their 

formats  are  then  provided  in  Volumes  II  and  III;  Volume  II  concerns  the 

inputs  needed  by  Combat  Interactions  Procedures  while  Volume  III  concerns 

2 

those  used  by  Command,  Control,  and  Intelligence  (C  I)  Procedures. 
Finally,  Volume  IV  describes  the  forms  of  output  produced  by  INWARS. 
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CHAPTER  II 
INWARS  INPUTS 


I 


A.  INTRODUCTION 


a*4 


In  this  chapter,  the  types  of  inputs  required  by  INWARS  will  be 
surveyed.  The  range  of  information  ultimately  required  in  an  INWARS  run 
may  be  partitioned  into  five  broad  categories:  (1)  environmental  informa¬ 
tion,  (2)  Order  of  Battle  (OB)  information,  (3)  performance  information, 
(4)  doctrine,  policy,  and  procedure  information,  and  (5)  campaign  informa¬ 
tion.  Environmental  information  characterizes  the  physical  context  in 
which  the  conflicting  forces  Interact;  it  is  discussed  in  Section  B  below. 
Order  of  Battle  (OB)  Information  characterizes  the  forces  in  conflict  in 
terms  of  composition,  disposition,  strength,  tactics,  and  other  OB-related 
information  (see  Section  C).  Performance  information  characterizes  the 
abilities  of  the  force  elements  in  carrying  out  their  functions  and  inter¬ 
acting  with  other  friendly  and/or  enemy  force  elements  (see  Section  D). 
Doctrine,  pol icy,  and  procedure  information  characterizes  the  inference  and 

decisionmaking  processes  of  C^I  elements  at  Echelons  Above  Division  (EAD). 

2 

This  is  a  very  Important  category  in  view  of  the  INWARS  focus  on  EAD  C  l 
elements;  It  is  discussed  in  Section  E.  Finally,  campaign  information 
characterizes  the  overall  campaign  objectives,  operating  constraints  (if 
any)  and  initial  configuration  of  each  force  in  the  conflict  (see  Section 
F). 


B.  ENVIRONMENTAL  INFORMATION  INPUTS 


Environmental  information  characterizes  the  physical  context  in  which 
individual  force  elements  operate  and  interact.  This  information  will 
consist  largely  of  terrain  information  appropriate  to  many  different  uses 
of  the  model;  thus,  once  developed,  most  environmental  information  should 
require  little  modification  or  redevelopment. 
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INWARS  decomposes  the  theater  geography  into  contiguous  hexagonal 
regions  having  a  "diameter"  (across  faces)  of  9.45  kilometers.  Each  hex  is 
characterized  not  only  in  terms  of  its  relative  position,  but  also  in  terms 
of  such  terrain  attributes  as  terrain  type,  barriers,  rivers,  nationality, 
population  density,  nuclear  and  chemical  terrain  effects,  and  so  on.  For 
the  purposes  of  specifying  INWARS  inputs,  terrain  information  can  be  charac¬ 
terized  in  terms  of  hex  attributes  in  the  general  area  of  operations. 
Details  on  the  attributes  included  and  formats  for  their  specification  will 
be  found  in  the  User's  Manual,  Volume  II,  Section  K. 

C.  ORDER  OF  BATTLE  INFORMATION  INPUTS 

Because  of  the  entity-based  architecture  of  INWARS,  a  large  portion  of 
the  input  information  is  structured  around  individual  force  elements;  such 
information  generally  reflects  characteristics  and  capabilities  of  force 
elements  in  a  direct  fashion.  For  this  reason,  such  data  can  be  conven¬ 
iently  characterized  and  specified  in  Order  of  Battle  (OB)  terms  and  cate¬ 
gories.  These  include:  (1)  composition  information  (Section  1),  (2) 
strength  information  (Section  2),  (3)  disposition  information  (Section  3), 
and  (4)  tactics  information  (Section  4). 

1.  Composition  Information  Inputs 

As  an  OB  category,  composition  information  concerns  the  identifi¬ 
cation  and  organization  of  specific  units  and  commands.  Each  force  element 
to  be  Included  in  an  INWARS  run  must  be  identified  in  terms  of:  (1)  a  unit 

identity,  (2)  a  side  (NATO  vs.  Warsaw  Pact),  (3)  a  nationality,  (4)  an 

2 

echelon  of  command,  and,  (5)  a  unit  type  classification  (e.g. ,  Cl  element, 
maneuver  brigade/regiment,  or  air  base  cluster).  In  addition  to  unit 
identification,  organizational  information  must  also  be  included  in  INWARS 
inputs.  This  amounts  to  a  specification  to  the  chain  of  command  among  the 
various  force  elements.  The  manner  In  which  such  Inputs  are  made  is 
discussed  in  the  User's  Manual,  Volume  II,  Sections  E  and  L  (especially 
L.l). 
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2.  Strength  Information  Inputs 

As  an  OB  category,  strength  information  refers  to  the  quantities 
of  material  and  men  possessed  by  a  unit  or  command.  For  the  purposes  of 
INWARS  inputs,  the  strength  information  category  is  used  analogously.  Each 
force  element  introduced  into  the  simulation  must  be  endowed  with  (initial) 
quantities  of  assets.  Of  course,  before  unit  strength  can  be  specified, 
the  types  of  assets  to  be  treated  in  the  simulation  must  be  established  and 
characterized.  While  it  is  not  expected  that  the  user  would  make  frequent 
changes  to  the  asset  typing  scheme,  INWARS  does  permit  such  changes  to  be 
made  via  data. 

The  range  of  asset  types  to  be  treated  in  INWARS  would  typically 
include  major  weapons  systems,  supplies  and  so  on,  but  would  exclude  such 
equipment  as  individual  weapons,  communications  equipment,  and  other  assets 
whose  functions  are  only  treated  implicitly  in  INWARS.  Potentially  signifi¬ 
cant  reductions  in  run-time  and  storage  will  accrue  to  a  limited  and  highly 
aggregated  range  of  asset  types  (e.g,  consisting  of  few  distinct  asset 
types).  Limitations  and  aggregations  in  this  area  also  appear  to  be 
consistent  with  the  overall  objectives  of  INWARS.  Within  the  simulation, 
each  asset  type  is  essentially  defined  by  a  block  of  parameters  which 
characterize  how  assets  of  that  type  operate  and  perform  under  varying 
conditionr  These  include,  for  example,  attrition  rates,  suppression 
parameters,  vulnerabilities,  and  so  on,  as  discussed  in  the  User's  Manual, 
Volume  II,  Section  F. 

Once  an  asset  typing  scheme  has  been  specified,  unit  strength 
information  can  be  specified  as  an  initial  state  variable  value  by  simply 
indicating  the  quantity  of  each  asset  type  possessed  by  the  unit  (as 
described  in  the  User's  Manual,  Volume  II,  Section  L  (especially  L.3)). 

3.  Disposition  Information  Inputs 

As  an  OB  information  category,  disposition  information  refers  to 
the  location  of  force  elements  and  their  tactical  deployment.  For  the 
purposes  of  specifying  INWARS  inputs,  disposition  information  is  thus  the 
category  under  which  force  elements  are  "placed"  on  the  ground.  Each  force 
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element  introduced  must  ult^iat’ly  be  assigned  a  particular  hex  address 
within  the  overall  hexagonal  decomposition  of  the  terrain.  In  addition  to 
locating  force  elements  in  the  hex  address  system,  disposition  specifica¬ 
tions  must  also  characterize  their  tactical  deployment  in  terms  of  "facing" 
within  the  hex  they  occupy,  their  initial  operating  objective,  sector 
responsibilities  and  so  on.  (See  the  User's  Manual,  Volume  II,  Section  L, 
especially  L.2  and  L.5). 

4.  Tactics  Information  Inputs 

As  an  OB  information  category,  tactics  information  concerns 
tactical  doctrine  (accepted  principles  of  organization  and  employment  of 
forces  for  the  conduct  of  operations)  as  well  as  tactics  employed  by  spe¬ 
cific  units  (manner  in  which  the  units  conduct  operations).  For  the 
purposes  of  specifying  INWARS  inputs,  tactics  information  is  the  category 
under  which  lower-echelon  force  elements  (divisions  and  below)  are  provided 

with  limited  capabilities  to  conduct  operations  and  react  to  the  situations 
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they  face.  (Because  of  the  INWARS  focus  on  higher-echelon  EAD  C  I 
processes,  corps  and  above  must  be  endowed  with  more  extensive  inference 
and  decisionmaking  capabilities,  specified  as  discussed  in  Section  E, 
below). 

To  specify  tactics  information,  the  range  of  permissible  opera¬ 
tion  types  must  first  be  determined.  Each  operation  type  must  first  be 
characterized  in  terms  of  its  effects  on  combat  processes  and  force  element 
interactions.  The  tactical  relationships  among  operation  types  and  situa¬ 
tion  perceptions  must  then  be  characterized  in  the  form  of  Operation  Reac¬ 
tion  Systems  (ORS's)  to  guide  the  various  types  of  force  elements.  As  with 
asset  types,  it  is  expected  that  operation  types  (and  the  related  defini¬ 
tional  data)  will  not  be  changed  frequently;  again,  however,  INWARS  permits 
such  changes  via  data  input. 

a.  Range  of  Operation  Types  to  be  Treated 

The  basic  determination  of  which  operation  types  should  be 

treated  in  INWARS  must  insure  that  enough  different  operations  are  treated 
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to  adequately  represent  the  operations  of  all  force  elements  (i.e.,  C  I 
elements  as  well  as  maneuver  brigades  and  regiments,  and  NATO  as  well  as 
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Warsaw  Pact  force  elements).  More  operations  "cost"  more  in  terms  of 
storage  requirements,  but  do  not  cause  extensive  increases  in  run-time.  On 
the  other  hand,  there  is  little  to  be  gained  by  adding  operations  which 
cannot  be  distinguished  in  terms  of  their  defining  physical  parameters  or 
operational  reactions. 

b.  Specifying  Operation  Effects  on  Combat  Processes  and  Force 

Interactions 

One  basic  role  of  operations  in  INWARS  is  to  provide  an 
operational  context  for  physical  combat  processes  and  force  interactions. 
They  do  this  by  supplying  operation-dependent  parameters  to  the  various 
process  and  interaction  representations.  For  example,  vulnerabilities  to 
various  forms  of  attack  (e.g.,  with  nuclear  weapons)  may  depend  on  a  force 
element's  type  of  operation.  Operations  are  thus  "defined",  at  least  in 
part,  by  the  parameters  they  supply.  The  parameters  are  input  as  described 
in  the  User's  Manual,  Volume  II,  Section  I. 

c.  Specifying  Operation  Reaction  Systems 

The  other  basic  role  of  operations  in  INWARS  is  to  provide 
an  operational  context  for  reactions  of  units  to  the  situations  they  face. 
The  mechanism  for  this  is  the  units'  Operation  Reaction  Systems  (ORS's). 
ORS  inputs  are  described  in  the  User's  Manual,  Volume  II,  Section  H  (see 
also  Section  J);  a  particular  force  element  may  be  assigned  to  use  a  parti¬ 
cular  ORS  as  described  in  the  same  volume.  Section  L  (see  especially  L.4, 
L.5,  and  L.6). 


D.  PERFORMANCE  INFORMATION  INPUTS 


Performance  information  concerns  the  abilities  of  force  elements  to 
perform  the  functions  associated  with  their  basic  type.  This  may  or  may 
not  involve  their  interactions  with  the  environment  or  with  other  force 
elements.  Of  course,  a  great  deal  of  performance  information  is  included 
in  the  specification  of  asset  types,  operation  types,  and  Operation  Reac¬ 
tion  Systems.  Three  other  notable  categories  include  information  collec¬ 
tion  parameters,  search  pattern  data,  and  nuclear/chemical  readiness  para- 
meters.  These  are  discussed  in  the  User's  Manual,  Volume  II,  Sections  C, 
D,  and  G,  respectively. 
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E.  OOCTRINE,  POLICY,  AND  PROCEDURE  INFORMATION 

The  fourth  major  category  of  INWARS  input  information  concerns  the 

operating  doctrines,  policies,  and  procedures  which  govern  the  behavior  of 
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force  elements  at  Echelons  Above  Division  (EAD).  Since  the  EAD  C  I 
processes  are  the  principal  focus  of  INWARS,  this  information  category 

includes  a  wide  variety  of  information  elements;  this  is  especially  true  in 

2  2 
view  of  the  C  I  design  which  attempts  to  define  C  I  behavior  through  data 

rather  than  code.  The  inputs  in  this  area  are  used  to  construct  the  Under- 

2 

standings  of  the  Situation  (UOS's)  by  which  EAD  Cl  elements  operate,  and 

may  be  considered  in  two  broad  categories:  (1)  Fundamental  Knowledge 

Information,  and  (2)  UOS  Specification  Information. 

1 .  Fundamental  Knowledge  Information  Inputs 

The  basic  doctrines  and  policies  by  which  INWARS  EAD  C^I  elements 

operate  are  contained  in  the  Fundamental  Knowledge  component  of  their 

UOS's.  This  Fundamental  Knowledge  does  not  change  over  the  course  of  a 

2 

single  run  in  INWARS.  However,  given  the  focus  on  EAD  Cl  processes,  it  is 
expected  that  doctrines  and  policies  may  be  varied  between  runs  as 
suggested  in  Chapter.  I,  Section  B,  above.  The  types  of  information 
included  in  these  inputs  are  Concept  Information,  Analysis  Parameters,  and 
Procedural  Information. 

a.  Concept  Information  Inputs 

2 

Perhaps  the  most  unique  category  of  EAD  C  I  input  informa¬ 
tion  relates  to  guiding  concepts  —  concepts  of  operation  and  concepts  of 

2 

weapons  employment.  INWARS  EAD  Cl  process  representations  embody  a 

"concept-guided"  approach.  The  user  supplies  the  model  with  certain 

abstract  guidance  ("concepts")  concerning  the  generic  forms  of  alternatives 

to  consider  in  specific  decisionmaking  contexts  (e.g. ,  development  of 

ground  operations  or  consideration  of  nuclear  weapons  employment).  Through 

a  sequence  of  specification  and  refinement  steps,  the  model  itself  is 

capable  of  "fitting"  any  of  these  abstract  concepts  to  the  particulars  of  a 
2 

given  EAD  Cl  element's  situation. 

Concepts  of  operation  guide  the  operations  development 
process.  A  concept  of  operation  in  INWARS  is  characterized  by:  (1)  suit¬ 
ability  requirements;  (2)  a  set  of  thresholds,  operating  standards,  and 
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other  parameters  characterizing  the  operation;  and,  (3)  an  (abstract) 

"operation  form"  specifying  who  should  be  doing  what  at  any  given  time. 
2 

Each  EAD  C  I  element  in  INWARS  must  be  provided  access  to  lists  of  offen¬ 
sive  and  defensive  concepts  of  operation,  ordered  in  terms  of  doctrinal 
preference.  Concepts  of  operation  inputs  are  described  in  the  User's 
Manual,  Volume  III,  Chapter  II,  Section  C. 

Weapons  employment  is  also  a  concept-guided  process  in 
INWARS.  Here,  however,  the  "abstract  guidance"  provided  by  the  user 
consists  of  sets  of  "weapons  employment  concepts"  concerning  which  types  of 

enemy  force  elements  should  be  targeted  and  what  effects  should  be 

o 

inflicted  on  them.  As  with  concepts  of  operation,  each  EAD  C  l  element 
must  be  provided  access  to  a  set  of  such  concepts  for  each  type  of  weapons 
ordered  by  doctrinal  preference.  Weapons  employment  concept  inputs  are 
discussed  in  the  User's  Manual,  Volume  III,  Chapter  II,  Section  D. 

b.  Analysis  Parameter  Inputs 

As  a  part  of  their  inference  and  decisionmaking  activities, 

2 

EAD  C  I  elements  in  INWARS  have  occasion  to  undertake  a  variety  of 
"analyses".  Examples  include  the  estimation  of  subordinate  progress  or  the 
updating  of  the  nuclear  threat  index  in  response  to  nuclear  indicators. 
Such  analyses  are  often  conducted  with  the  aid  of  various  parameters  (i.e. , 
expected  advance  rates,  force  balance  adjustment  factors,  and  indicator 
likelihood  ratios).  Certain  of  these  parameters  are  input  as  a  part  of 
Standard  Operating  Procedures  (SOP)  data;  others  relating  strictly  to  the 
employment  of  weapons  are  input  as  Weapons  Parameters.  These  are  discussed 
in  the  User's  Manual,  Volume  III,  Chapter  II,  Sections  A  and  E,  respec¬ 
tively. 

c.  Procedural  Information  Inputs 

EAD  C  I  element  inference  and  decisionmaking  activities  are 

2 

generally  broken  up  into  smaller  "Cl  tasks"  within  the  model.  During  the 
performance  of  a  given  task,  other  derivative  tasks  may  be  indicated.  As 
an  example,  during  the  interpretation  of  a  unit  intelligence  message,  it 
may  become  apparent  that  force  balance  should  be  recomputed  (due,  e.g. ,  to 
a  "significant  change"  in  perceived  enemy  strength).  To  a  limited  extent, 
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INWARS  gives  the  user  control  over  these  procedural  links  among  C  I  tasks. 
In  the  example,  user-supplied  data  establishes  thresholds  of  significance 
for  changes  in  strength  and  other  information  elements;  it  also  determines 
which  potential  future  tasks  will  be  flagged  as  derivative  actions  to  be 
undertaken  upon  recognition  of  a  "significant"  change.  This  information  is 
input  as  the  "Updating  Thresholds  and  Flags"  data  described  in  the  User's 
Manual,  Volume  III,  Chapter  II,  Section  6. 

2.  UQS  Specification  Inputs 

Beyond  the  fundamental  knowledge  inputs,  certain  information 
specific  to  particular  EAD  forces  must  be  input  to  complete  the  specifica¬ 
tion  of  the  UOS's.  This  includes  the  identities  of  supporting  force 
elements  (e.g. ,  air  support  and  nuclear  or  chemical  weapons  delivery 
support),  initial  characterization  of  subordinate  force  element  roles  and 
reserve  relationships  (if  any),  initial  nuclear/chemical  readiness,  and 
nuclear  and  chemical  weapons  initially  authorized  for  employment  (if  any). 
These  inputs  are  described  in  the  User's  Manual,  Volume  III,  Chapter  III. 

F.  CAMPAIGN  INFORMATION  INPUTS 

Up  to  this  point,  the  inputs  have  characterized  the  conflict  environ¬ 
ment,  the  forces  in  conflict,  their  performance,  and  the  doctrines, 
policies,  and  procedures  by  which  they  will  operate.  All  that  remains  is 
to  specify  the  campaign  information  --  objectives  as  well  as  guidelines  and 
constraints,  if  any  -  which  will  "drive"  the  conflicting  forces.  Of  this 
information,  objectives  are  the  most  significant.  Guidelines  on  resources 
availabilities  and  constraints  on,  e.g.,  nuclear  or  chemical  weapons  employ¬ 
ment  must  also  be  included  as  a  part  of  the  campaign  information.  This 
information  is  input  as  described  in  the  User's  Manual,  Volume  III,  Chapter 
IV. 
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CHAPTER  III 
INWARS  OUTPUTS 


A.  INTRODUCTION 

In  this  chapter,  the  outputs  produced  during  an  INWARS  run  will  be 

surveyed.  These  outputs  are  of  two  basic  types:  (1)  physical  state  snap- 

2 

shots,  and  (2)  EAD  C  I  Element  Understanding  of  the  Situation  (UOS)  snap¬ 
shots.  These  outputs  are  discussed  briefly  In  Sections  B  and  C,  below. 
Further  discussion  of  INWARS  outputs  will  be  found  In  Volume  IV  of  this 
User's  Manual. 


B.  PHYSICAL  STATE  SNAPSHOTS 


Physical  state  snapshots  represent  the  "true"  state  of  the  simulation 
at  a  given  point  in  Lime.  They  are  taken  periodically  over  the  course  of 
the  simulation  and  provide  Information  about  each  force  element  in  the 
simulation  at  that  time.  Organized  on  a  force-el ement-by- force-element 
basis,  these  outputs  Include  disposition  Information  (hex  location,  facing, 
direction  and  speed  of  movement),  strength  Information  (aggregate  strength 
as  well  as  detailed  breakout  by  asset  type),  and  operational  status  inform¬ 
ation  (mission,  objective,  current  operation,  axis,  sector  width,  and 
nuclear/chemical  readiness).  The  form  and  content  of  these  output  informa¬ 
tion  elements  Is  described  in  the  User's  Manual,  Volume  IV,  Chapter  II. 


C.  C2I  ELEMENT  UOS  SNAPSHOTS 

2 

UOS  snapshots  give  the  user  access  to  each  EAD  C  l  Element's  Under¬ 
standing  of  the  Situation  (UOS).  These  snapshots  may  or  may  not  correspond 
to  the  "true"  physical  state  snapshots  due  to  EAD  Cl  elements'  imperfect 
perceptions  and/or  time  delays  in  receiving  current  situation  information. 
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Nonetheless,  they  are  the  basis  upon  which  the  EAD  C  l  elements  are  con¬ 
ducting  their  operations  at  the  time  of  the  snapshot.  Like  physical  state 

snapshots,  UOS  snapshots  are  taken  periodically  over  the  course  of  the 

2 

simulation  for  all  EAD  C  I  elements;  in  addition,  limited  UOS  snapshots  are 

2 

taken  for  individual  EAD  C  l  elements  at  key  decision  points.  As  is 
described  in  the  User's  Manual,  Volume  IV,  these  snapshots  may  include 
Situation  Data  (Own  Status,  Enemy  Order  of  Battle/Target,  and  Situation 
Features  Information)  and  Operations  Data  (Operative  Operation  Directive, 
Operative  Concept  of  Operation,  Progress  Management,  Weapons  Management, 
and  Readiness  Management  information).  In  addition,  temporary  Weapons 
Employment  Plans  may  be  output  if  they  are  to  be  "acted  on"  as  a  part  of 
Weapons  Employment  activities. 


